@evetion if you want to have a look at this it would be good to get it merged soon so we can use it in tests.

There are still a few types left to test but comments on overall structure would be good at this stage.

The idea is geometry constructors and methods are all defined in an @eval loop so they all behave the same way, just with varied levels of nesting and diferent child types/traits. Point is defined on its own as it's quite different.

This is ready to go

@evetion @visr can I get a review for this? It's needed to finish the LibGEOS convert PR.

A question I have is: should the types go in a module they can be easily imported, instead of all exported

should the types go in a module they can be easily imported, instead of all exported

My first thought would be to not export them as they will often clash with other packages. Putting them in a module works, perhaps combined with making them available unexported in the GeoInterface namespace as well, such that GI.Point also works.

Can you elaborate a bit on how/where/why you want to use these wrapper types? Is it still mainly to make it easier to work with Base types that we consider to be GeoInterface compatible objects, and arrays thereof, as mentioned in the first post? Maybe the answer could go straight to the docs ;)

Reasoning:

1. Tests. We are defining objects everywhere for tests but they are rarely flexible enough to do real testing of all the edge cases.
2. Types that are missing in packages. Not every package implements everything, and wrappers can be used to fill those gaps
3. Users cobbling together arbitrary geometries into objects from base points or any other geometries - even mixed together. This is currently really hard. How do we just make a LineString out of any kind of point? you have to learn it again and again for every package.
4. Packages cobbling together objects for internal users e.g. MultiPolygons from polygons. How can they currently do that generically for any GeoInterface.jl compatible polygons without a dependency?
5. Creating arbitrary features and feature collections. Not possible in half the packages and very useful to have a general method, see e.g. Allow plotting Vectors of geometries with GeoInterfaceMakie.jl #79

Thanks! Would you mind adding this to the docs as well? Perhaps also including when it's not needed/helpful to use these? For packages like GeoJSON and GeometryBasics I guess there is not directly much benefit from these, or not?

Yeah, I will add that.

Its actually pretty beneficial to GeometryBasics.jl as it has no Feature/FeatureCollection concept, again see this for a use case #79.

Also most packages (e.g. Rasters.jl) don't know about these packages or depend on them, so would still use the wrapper type over the package type as its generic. Even if GeoJSON has its own types how would we know about them without a dependency, and why would we write anything package specific when we don't have to.

I imagine it will be the same for users. Just learn one set of wrappers and use them everywhere, even if there are native types why bother learning that.

(this generality is made more useful with the PRs I'm making to ArchGDAL/LibGEOS etc - they don't care about geometry types anymore anything will work)

This is good to go, with a section in the docs.

I simplified it to just include the main types needed for e.g. LibGEOS tests.

We can work through issues (like with how to construct Triangle) later on, best to get this merged before I run out of steam to finish this and the PRs depending on it.

Coverage is up at 98%, and it seems like everthing makes sense - using it in LibGEOS tests seems to work well.

@visr @evetion can I get an approval to merge this?

🎉 I'll try to review tomorrow

Closes #75

@evetion thanks for the super-thorough review, gives me a lot of confidence in quality of the PR and the interface generally.

It made me think we should aim for 100% coverage and this degree of correctness now that we are not rushing to just get the basics working.

Ok this has 100% coverage.

@evetion want to give this one last review? then we can squash and merge.

(it really needs squashing, there are a lot of trash commits here)